The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
Software applications operating in a network environment exchange application messages. An “application message,” or simply “message”, as used herein, refers to a message emitted or consumed by a software element that is logically located at Layer 5 or higher of the OSI reference model. Messages may be contained in more than one data frame, packet or segment. For simplicity, the term “packet” is used to refer to a unit of organization under an internetworking protocol, such as data frame, packet or segment, at Layer 2, 3 or 4 of the OSI reference model.
Application end points such as clients and servers in a distributed system communicating over a network often need to authenticate users' credentials presented in an application message and, if the authentication succeeds, authorize the users for specific privileges for using system or application resources. Authentication and authorization usually is done by application end points. Application end points, or simply applications, are required to perform authentication and authorization operations relating to messages received. Under this approach, logic extracting user credentials from application messages is part of application processes. However, to perform the extraction, applications need to know specific details of application message formats such as where user credentials are stored.
Additionally, authentication or authorization logic often communicates with one or more authentication or authorization service providers or data stores. Thus, applications often need to know specific details of service providers or data stores such as where and how the user credentials extracted from messages can be compared with trusted user credentials kept by the service providers or data stores. To complicate the matter, some service providers or data stores may not be based on industry standards in providing the authentication or authorization related services.
Applications' needs for authentication and authorization may change. For example, service provider may change. An application may need to support LDAP, instead of Kerberos for authentication. Or an application may need to access a data store, instead of a service provider.
Furthermore, formats of application messages may change with respect to user credentials. User credentials may be specified in an application protocol header (say HTTP header) or SOAP header. Also they can come as a part of application message body in an application specific format, or in a payload.
Generally, in past approaches, in order to handle any of these changes, the implementation of the application has to be changed. This is time-consuming and requires significant resources in programming labor.
Further, in typical past approaches, the number of points at which authentication and authorization are performed is proportional to the number of application endpoints. This is a waste of application processing resources.
Also, in typical past approaches, authentication and authorization by an application can only authenticate and authorize based on user credentials present in an application message. Since the application typically is ignorant of what user credentials may present below OSI layer 5, authentication and authorization for such user credentials typically has to be performed elsewhere. An example of such user credentials is an SSL certificate. This results in a fragmented processing, waste of resources and potential inconsistent outcome.
In past approaches, network elements such as routers and switches generally have had limited or no support for application program extensibility, in which customers or users of the network elements can define their own software programs and upload the programs into the network element. To address the problems above relating to authentication and authorization, and other problems, Cisco Systems, Inc. has introduced Application Oriented Network (AON) technology, which provides an environment in which customers can create programs that can be dynamically loaded and executed on the network device.
The availability of extensible programs creates the possibility that a customer program will attempt to write system memory, change configurations, destroy disk files, or perform other operations that may be harmful or disruptive to the network element. The network element should be protected from such harm.
One approach to allow custom code to be uploaded into a network element involves creating a new image containing the new functionality. Access control and security for such code is controlled at build time, or by providing options to control behavior of the module via a command line interface. Thus, the problem of code behavior is addressed in a static manner, and cannot change dynamically after the code has been uploaded and executed. The standard security mechanism of the Java Virtual Machine (JVM) does not allow the running security policy to be changed dynamically. In other words, changing the security policy requires the JVM to be restarted, which is undesirable.